At present, the 3rd Generation Partnership Project (generally known as ‘3GPP’) has introduced the basis for an IP Multimedia Subsystem (generally known as ‘IMS’) and IMS services, as stated in the technical specification 3GPP TS 23.228 V6.6.0 (2004-06). In accordance with 3GPP, and derived from the introduction of standardised presence, messaging, conferencing, and group service capabilities in the IMS, there is a need for Public Service Identities. These Public Service Identities are different from the Public User Identities in the respect that the former identify services, which are hosted and operated by application servers (generally known as ‘AS’ in at least said 3GPP technical specification), whereas the latter identify users whose subscription data are hosted in subscriber databases under network operator premises, and who are served by different serving network nodes such as a Serving Call Session Control Function (known as ‘S-CSCF’ under 3GPP).
Generally speaking, Public Service Identities are used to identify services running on specific application servers. In particular, Public Service Identities are used to identify groups of services such as a chat-type service, for instance, that may use a Public Service Identity (hereinafter referred to as ‘PSI’) to which the users may establish a session in order to enable the sending and reception of messages from other session participants. Public Service Identities are presently assumed to take the form of SIP URL or SIP URI as defined by the Internet Engineering Task Forces (IETF) in RFC 3261 and RFC 2396, as well as in the so-called ‘tel:’-URL format as defined in RFC 2806. An exemplary Public Service Identity (PSI) identifying a chat-type service may be sip:chatlist_X@example.com.
In accordance with the above 3GPP technical specification, and as an important issue aiming the present invention, the IMS must be provided with a mechanism for users and network operators to create, manage, and use Public Service Identities under control of specific application servers (AS). More specifically, there is a need for a mechanism to make possible the creation of Public Service Identities both statically, such as by means of an Operation and Maintenance system (hereinafter referred to as ‘O&M’) under control of the network operator, and dynamically by the users themselves.
As already introduced above when differentiating Public Service Identities from Public User Identities, each Public Service Identity (PSI) is hosted by an application server (AS), which executes the service specific logic as identified by the Public Service Identity. In other words, an application server runs a particular service identified by a Public Service Identity. In operation, the IMS provides the means for routing IMS messages related to particular IMS services by using corresponding Public Service Identities.
Therefore, as the above 3GPP technical specification states, Public Service Identities, which are created either statically by O&M or dynamically by the users, are stored in a Home Subscriber Server (generally known as ‘HSS’) holding subscription data for subscribers of a home network operator. A server acting as an HSS may thus know how to route any message involving a particular Public Service Identity (PSI) towards an appropriate application server (AS) hosting a correspondingly identified service. To this end, the HSS knows for each Public Service Identity (PSI) an identifier (AS-Id) of the application server (AS) where the corresponding service runs. In this respect and from a conceptual point of view, the identifier (AS-Id) of the application server running a service, along with the Public Service Identity (PSI) identifying the service, are stored in the HSS and have an entry in said HSS that is referred to as a ‘PSI user’.
The explanations given hereinbefore imply some consequences, or rather some requirements that Public Service Identities are supposed to fulfil. On the one hand, the uniqueness of each Public Service Identity (PSI) to be created must be ensured. On the other hand, this uniqueness does not only apply in respect of other existing Public Service Identities but also in respect of the existing Public User Identities already defined under network operator premises. Bearing in mind the uniqueness of a Public Service Identity (PSI), a further and important issue also aiming the present invention is the handling of wildcard Public Service Identities.
In this respect, Public User Identities can adopt two different forms of representation and scope. A first one is a so-called ‘Distinct PSI’, such as sip:my_service@example.com. As stated in 3GPP technical specifications, the ‘Distinct PSI’ may be created, modified and deleted in the HSS by the operator via O&M mechanisms, as well as by an application server (AS) via a 3GPP-defined ‘Sh’ interface. Also in accordance with 3GPP, there is a need for allowing a ‘Distinct PSI’ to be created and deleted by users using a 3GPP-defined ‘Ut’ interface.
A second scope and form of representation is a so-called ‘Wildcard PSI’, such as sip:chatlist_*@example.com, wherein a range of Public User Identities is defined with a same domain part in the SIP URI and with a wildcard indication in the user part of the SIP URI. ‘Wildcard PSI’ ranges may be created, modified and deleted in the HSS by the operator via O&M mechanisms, whereas individual Public User Identities within a ‘Wildcard PSI’ range may be created and deleted by users using the above 3GPP-defined ‘Ut’ interface towards an application server (AS) hosting said ‘Wildcard PSI’ range. Individual Public User Identities within a ‘Wildcard PSI’ range may be created and deleted by the operator directly in the application server (AS) via O&M mechanisms as well.
Currently existing mechanisms do not describe how a PSI can be created, modified or deleted, by the operator or by the user, and how PSI routing can be solved in different usage scenarios. More precisely, the current technical specification does not identify some drawbacks derived from the current state of art.
A first drawback to solve, and aiming the present invention is the PSI uniqueness. So far, the standard does not propose any mechanism to ensure PSI uniqueness when a PSI is created and populated by either an end-user, by an O&M under operator premises, or by an application server itself. Moreover, the PSI uniqueness is not only to be checked against existing Public Service Identities, or against Public User Identities, but also against any ‘Wildcard PSI’ wherein a PSI belonging to a range might match a PSI to be created into a given domain.
Moreover, each PSI may be hosted by a specific application server (AS) and, therefore, the application server may request the use of a specific format for the PSI. The state of the art does not consider the selection of a PSI format by the application server and how the uniqueness is assured in case that several application servers make use of the same PSI format. Thereby, the use of ‘Wildcard PSI’ ranges through different application servers is also an issue aiming the present invention.
Further, a PSI dynamically created in an application server, either by an end-user or directly created by the application server itself, needs to be populated in an HSS as a result. Therefore, the 3GPP specification proposes the use of the 3GPP-defined ‘Sh’ interface. However, an application server is not traditionally arranged to arbitrarily select an HSS in which the PSI can be stored, where more than one HSS exist in the network. Moreover, and in accordance with currently existing trends, an application server (AS) is not supposed to be aware of the architecture of deployed HSS servers. Thereby, the creation, management and use of a PSI and a ‘PSI user’, where more than one HSS exist in the network, are relevant issues aiming the present invention.
In addition, the creation and deletion of a PSI by application servers require the consideration of security mechanisms to allow a secure handling that is not covered by current solutions. Thus, a further aim of the present invention is the provision of a secure handling of a PSI, in terms of creation, modification and deletion of said PSI, in order to preclude a misuse of network operator premises.
Therefore, an object of the present invention is the provision of a mechanism whereby a Public Service Identity (PSI) may be created by either an end-user, by an O&M under operator premises, or by an application server itself, and populated in one among a plurality of Home Subscriber Servers whilst ensuring the PSI uniqueness against existing Public Service Identities, existing Public User Identities, and also against any existing ‘Wildcard PSI’ range.